1. Field of the Invention
The present invention relates generally to the data processing field and, more particularly, to a computer implemented method, system and computer usable program code for facilitating the utilization of complex data objects.
2. Description of the Related Art
Many applications require a mechanism for storing and persisting information. This information is commonly represented, processed and manipulated at runtime by wrapping it in Java™ objects, which may also provide functions external to the information. One example is the Java™ security “Permission” classes wherein, in addition to the information specifying the resource they are protecting, the implementing classes also provide an implies( ) method for runtime evaluation of access requests.
The inventors have recognized that a problem to be solved is how to extract and efficiently store data wrapped by an object such as a Java™ object while, at the same time, enable access to runtime functions that the object provides when they are needed. Furthermore, inasmuch as the primary target for the extracted data is some form of storage mechanism, the inventors have also recognized additional requirements that should also be satisfied in order to fully solve the problem.
First, the storage of large data sets implies a method for finding information within the sets. Therefore, the extracted data should be in a format that is conducive to searching. A common method for finding data is a parameter-value lookup, for example, finding all Permissions whose “Actions” parameter has the value “GET”.
Second, the format of the extracted data should be independent of any individual storage mechanism as one method of storage is not suitable for all applications. One installation of a product may require support for a large number of objects with efficient lookup and between-session persistence, which could be implemented via a database backend; however, another installation may only require a small number of objects and no persistence, meaning using a database backend would have too much overhead. Thus, solution of the problem includes supporting conversions to different storage formats.
Third, it should not be necessary to have to modify existing classes, nor should newly implemented classes need to implement any extra interfaces.
A standard method for providing persistence for Java™ objects is to use the Object Serialization system. This method, however, has a number of deficiencies that make it unsuitable as a solution for the problem of extracting and efficiently storing data wrapped by a Java™ object while, at the same time, providing access to the runtime functions that the object provides. Such deficiencies include:                Data must be provided and read as streams, and therefore may not be in a human-readable form. Serializing data in a human-readable manner is desirable from a support perspective as visually inspecting data can greatly increase the ability to diagnose problems.        The default behavior is to store all information regarding an object, including private members. Private members of a class should be regarded as implementation details, and it may not be desirable from a security perspective to persist this data.        While it is possible to implement a custom format for serialized objects, all objects needing to be serialized must be modified to use this format. This means that existing classes cannot use a custom format without modification, and this may not be possible for SDK (Software Development Kit) or standard J2EE classes.        Also, Java™ serialization does not facilitate searching by attribute, ie, the Actions=“GET” example referred to above would require that the bytecode be interpreted.        
Solutions also exist for serializing objects as XML (extensible Markup Language) [such as XStream {http://xstream.codehaus.org/}]. While these solutions provide a human-readable format for storage, they are tied to a single representation (XML) and more information is extracted than is necessary (private members). This causes XML serialization solutions to suffer from the same problem as Java™'s Object Serialization, i.e., they are too heavy-weight and inflexible.
There is, accordingly, a need for a mechanism for flexibly and efficiently facilitating the utilization of a complex data object such as a Java™ object or an XML object while, at the same time, providing access to runtime functions that the object provides.